SAMBA - INSTALACJA, KONFIGURACJA, ADMINISTRACJA
© 2001-11-20
Bartek Siębab
ver. 1.8
WSTĘP
Czym jest Samba?
W niniejszym artykule starałem się przedstawić pokrótce serwer plików
i drukarek w sieciach TCP/IP zgodny usługami udostępniania w sieciach Windows®.
Zamiast ponosić wysokie koszty zakupu Windows NT® lub Windows 2000® możemy
zainstalować na serwerze uniksowym darmową Sambę, która dla pecetów w sieci działa i zachowuje się
dokładnie jak powyższe oprogramowanie firmy Microsoft. Uzyskujemy jednocześnie środowisko
o nieporównanie większych możliwościach rozwoju i skalowalności.
Opracowanie ma charakter uniwersalny, w miarę możliwości niezależny od
systemu operacyjnego na którym instalujemy i konfigurujemy Sambę w
wersji 2.0.9. INSTALACJA
Każdy system posiada wsparcie dla instalowania dodatkowych pakietów
oprogramowania (np. ports, packages we FreeBSD lub RPM w Linux), tak
więc najprościej skorzystać z tego udogodnienia aby zainstalować
najnowszą wersję Samby. Jednak chcąc zachować uniwersalność tego
artykułu wykonamy to "na piechotkę". Obecnie zalecana wersja
Samby to 2.0.9 w której wyeliminowano bug w zapisie tymczasowych plików
kolejki
wydruku w sposób niekontrolujący istnienia linków do innych plików, co
mogło
prowadzić do naruszenia bezpieczeństwa. Najnowsza wersja Samby z nowej
gałęzi
rozwojowej to 2.2.2 i wspiera ona system autoryzacji w domenie
NT/Windows 2000.
Całość procesu opisanego w artykule wykonujemy jako superużytkownik root.
Z polskiego mirrora ściągamy, rozpakowujemy, konfigurujemy i kompilujemy dystrybucję Samby:
$>cd /usr/install
$>wget -c -o log.txt ftp://giswitch.sggw.waw.pl/pub/unix/samba/samba-2.0.9.tar.gz
$>tar -zxvf samba-2.0.9.tar.gz
$>cd samba-2.0.9/source
$>./configure --localstatedir=/var/log/samba --sysconfdir=/etc
$>make && make install && make clean
Są dwa sposoby uruchamiania usług Samby, standardowo poprzez inetd
lub jako daemony (np. z /usr/local/etc/rc.d/samba.sh). Prostszym i
łatwiejszym, a zarazem efektywniejszym dla małych instalacji (rzędu
<30 pecetów) jest start usług z /etc/inetd.conf. Po dopisaniu obu
linijek musimy powiadomić inetd o zmienionej konfiguracji i sprawdzamy
czy usługi zostały uruchomione. Formalnie należy także sprawdzić czy w
pliku /etc/services są odpowiednie wpisy (sieć Windows® "okupuje" porty
137, 138, 139). Jest jeszcze trzeci wpis dotyczący usługi konfiguracji
Samby poprzez przeglądarkę (Swat) o czym można przeczytać w
dokumentacji. Ze względów bezpieczeństwa nie polecam tej usługi,
dlatego tutaj nie będziemy jej uruchamiać. Przed startem usług należy
jednak stworzyć poprawny plik konfiguracji zasobów Samby, o czym
później.
$>cd /etc
$>cat inetd.conf | grep netbios
/etc/inetd.conf:
# Enable the following two entries to enable samba netbios startup from inetd
# (from the Samba documentation) netbios settings:
netbios-ssn stream tcp nowait root /usr/local/samba/bin/smbd smbd
netbios-ns dgram udp wait root /usr/local/samba/bin/nmbd nmbd
$>killall -HUP inetd
$>netstat -a | grep netbios
tcp 0 0 *.netbios-ssn *.* LISTEN
udp 0 0 venom.netbios-dgm *.*
udp 0 0 venom.netbios-ns *.*
udp 0 0 *.netbios-dgm *.*
udp 0 0 *.netbios-ns *.*
KONFIGURACJA
Przystępujemy do stworzenia poprawnej konfiguracji
udostępnianych zasobów. Przed tym jednak zmodyfikujemy usługi
drukowania serwera pod kątem udostępnienia drukarki sieciowej dla
naszych pecetów. W systemach *BSD odpowiednie wpisy muszą się znaleźć w
pliku /etc/printcap.
$>grep -v ^\# printcap
hpdj|lp|Atramentowka HP DeskJet:\
:sh:rw:sf:mx#0\
:lp=/dev/lpt0:sd=/var/spool/output/lpd:lf=/var/log/lpd-errs:
Warto tutaj wspomnieć, że pozycja mx#0 jest wymagana do poprawnej
pracy drukarki i wyłącza limit wielkości pliku wysyłanego do drukarki
(domyślnie 1MB). Większość problemów wynikająca z dziwnego zachowania
drukarki przy wydrukach z Windows® wynika z braku tegoż wpisu.
Zakładamy, że uniksowy daemon drukowania został zrestartowany i działa
poprawnie po dokonaniu zmian w /etc/printcap.
Przejdźmy zatem do konfiguracji zasobów udostępnianych przez
Sambę. Tworzymy i edytujemy plik /etc/smb.conf dokonując wpisów
wymaganych dla poprawnego działania naszej sieci. Po modyfikacjach
warto przetestować poprawność składniową pod kątem wystąpienia m.in.
literówek itp. (polecenie testparm).
Najprościej będzie dostosować do własnych potrzeb poniższy plik konfiguracji.
Bogato opatrzonego komentarzami
cytuję go tutaj w całości.
W dalszej części artykułu omówię wybrane, ważne aspekty tej
konfiguracji. Pomoc na temat poszczególnych parametrów jest dostępna w
dokumentacji Samby. Obejrzymy ją wydając polecenie "man smb.conf".
Podczas instalacji Samby, oprócz dokumentacji i manuala, otrzymujemy
doskonałą książkę w postaci stron html. W systemie FreeBSD domyślnie
jest ona instalowana w katalogu "/usr/local/samba/swat/using_samba".
Nosi ona tytuł "Using Samba" autorami są R.Eckstein, D.Collier-Brown, P.Kelley.
Tutaj zamieszczam polskie wydanie tej ksiazki w pdf'ie (3,6MB).
Listing pliku konfiguracji Samby (smb.conf) nie zmieścił się w wydaniu Software nr. 11
z powodu jego wielkości, został jednak umieszczony na płycie CD sprzedawanej
wraz z numerem. Jest umieszczony wraz z innymi listingami na CD w pliku \Opis\listingi.html
a jego najnowsza wersja jest poniżej.
$>cat /etc/smb.conf
###################################################################
# sekcja globalnej konfiguracji Samby
# (c)2000,2001 bs@vt.pl
#
[global]
comment = Polaczenie z venom ...
log file = /var/log/samba/%I.log
dont descend = /dev,/proc,/root,/stand,/bin,/dist,/etc,/lkm,/mnt,/sbin,/sys,/usr
# opcje dla 10/100Mbit Half/Full Duplex
# takie ustawienie daje maksymalną szybkość w LAN
# w zależności od specyfiki konkretnej sieci, może wymagać modyfikacji
socket options = TCP_NODELAY SO_SNDBUF=16384 SO_RCVBUF=16384 IPTOS_LOWDELAY
# włączenie tych dwóch opcji zwiększa zwykle szybkość Samby o kilkanaście procent
# choć z moich analiz wynika, że praca z bazami danych jest trochę szybsza bez tego
read raw = yes
write raw = yes
# buforowanie katalogów
getwd cache = yes
# buforowanie zapisu plików zdecydowanie poprawia prędkość
# ale stwarza niebezpieczeństwo że Samba "nie zdąży" zrzucić buforów na dysk
# przy np. padzie zasilania (bez ups'a) plik taki będzie uszkodzony
# coś za coś, stosować z umiarem ;)
write cache size = 65536
# nadajemy Sambie nazwę w sieci windows
netbios name = venom
# chcemy mieć w miarę szczegółowe logi z dostępu do plików i zasobów
debug level = 2
debug timestamp = no
timestamp logs = True
# wielkość logów na peceta w KB, logi automatycznie przycinane przez Sambę
# czyli w rzeczywistości mamy zawsze po dwa pliki: oryginał i oryginał.bak
max log size = 5000
# chcemy aby Samba "słuchała" tylko na jednej z kilku naszych kart sieciowych
bind interfaces only = True
interfaces = 10.0.0.1/255.255.255.0
hosts allow = localhost, 10.0.0.0/255.255.255.0
# tutaj konfigurujemy sposób obsługi drukowania
printing = bsd
printcap name = /etc/printcap
map archive = no
status = yes
public = no
read only = no
lpq cache time = 10
# tutaj ustawiamy opcje dotyczące konwersji nazw plików, wielkości liter itp.
preserve case = yes
short preserve case = yes
strip dot = no
hide dot files = yes
# strona kodowa na pecetach
client code page = 852
# strona kodowa na uniksie
character set = iso8859-2
# tryb poziomu bezpieczeństwa zasobów
# (user=wymagane konto na uniksie oraz konto samby)
security = user
guest ok = no
browseable = yes
# domyślny tryb tworzenia plików -rw------
create mode = 0700
# to odpowiada za superdostęp którego jednak nie chcemy :)
# admin users = root
# przydatne
unix realname = yes
# każdy dozwolony zapis do pliku zmienia timestamp pliku (jak w dos)
dos file times = yes
# ustawiamy grupę roboczą naszej sieci
workgroup = vtest
# zrzucamy połączenie po czasie 15minut w przypadku braku otwartych plików
# lub braku odpowiedzi z peceta
dead time = 15
keep alive = 15
# parametry ilości otwarych plików, zasobów itp.
mangled stack = 100
shared mem size = 1048576
max open files = 500
# chcemy aby Samba obsługiwała wyświetlanie wszystkich zasobów sieci, oraz udostępniała
# tzw roaming profiles (jak w NT)
domain master = yes
local master = yes
preferred master = yes
# ponieważ mamy tylko jedną podsieć, "cross subnet browsing"
# nie będzie nam potrzebny. Być może zrobimy drugą podsieć, zatem włączymy usługę WINS
wins support = yes
os level = 64
# niech nasza Samba działa "prawie" jak NT
nt smb support = yes
nt pipe support = yes
nt acl support = no
# Logowanie do domeny dla Windows 3.x, 95, 98,
# przechowywanie profili użytkowników na serwerze
# włączenie skryptów logowania mapujących np. dyski, drukarki itp.
domain logons = yes
logon script = startup.bat
logon path = \\%L\%U
# chcemy żeby wszystkie pecety synchronizowały datę i czas zgodnie
# z naszym serwerem (jak w NetWare)
time server = True
# kolejność w jakiej Samba robi rozwiązywanie nazw netbiosowych pecetów
name resolve order = wins bcast hosts lmhosts
# nie chcemy, aby hasło windows'a = hasłu uniksa
# bowiem wymaga to specyficznego skonfigurowania procedury synchronizacji
# zależnej od konkretnego uniksa
unix password sync = false
update encrypted = no
passwd program = /usr/bin/passwd %u
passwd chat debug = false
passwd chat = *New*password* %n\n *Retype*new*password* %n\n *updating*done*
# chcemy, żeby hasła były szyfrowane (jak w Windows 98, NT),
# Windows 95 wymaga przestawienia na taką pracę
# poprzez modyfikację rejestru. Odpowiednie pliki *.reg są dostępne w źródłach Samby.
# Tryb pracy z szyfrowanymi hasłami Samby pozwala na zmianę
# hasła sieciowego z poziomu "Panelu sterowania" w Windows.
encrypt passwords = yes
null passwords = false
# Komentarz widoczny w trybie szczegółów w "Otoczeniu sieci" Windows
server string = Serwer Venom
# Sekcje konfiguracji zasobów Samby
###################################################################
[homes]
# ta sekcja mapuje uniksowy katalog $HOME użytkownikowi
comment = Twoj wlasny katalog
# przykładowo, prawa na katalogach domowych użytkowników /home
# powinny wyglądać tak:
# $>ls -l /home
# drwx------ 3 piotrek piotrek 512 22 Sty 2000 piotrek
# prawa do plików i katalogów tylko dla właściciela
create mode = 0700
directory mode = 0700
public = no
writable = yes
# ścieżka do zasobu (czyli $HOME z /etc/passwd)
path = /home/%u
browseable = no
# zezwalamy na agresywne buforowanie plików przez Windows co
# daje znaczące zwiększenie szybkości Samby.
# Bezsensownym jest stosowanie tego na zasobach bazodanowych itp.
# "oplock" = "opportunistic lock"
oplocks = True
level2 oplocks = True
# przykładowo zabraniamy oplock'ów na plikach *.dbf i *.DBF
# veto oplock files = /*.DBF/*.dbf/
###################################################################
[netlogon]
# ta sekcja udostępni zasób dla wszystkich, przy logowaniu do serwera
# w którym trzymamy globalny logonskrypt,
# pliki założeń Windows Policy (config.pol) - patrz dokumentacja Windows,
# a w szczególności program poledit.exe. Windows przy logowaniu nakłada
# parametry i ograniczenia pobierane z pliku config.pol na logującego się
# użytkownika. Modyfikowany jest rejestr tego użytkownika.
# prawa na katalogu powinny być takie:
# drwxr-xr-x 2 root wheel 512 14 Sty 2000 netlogon
comment = Net Logon Service
path = /home/netlogon
case sensitive = no
create mode = 0755
directory mode = 0770
guest ok = yes
# nie potrzebujemy blokowania plików bo zasób jest tylko do odczytu
locking = no
writable = no
share modes = no
browseable = yes
# pozwalamy jednak na zapis do niego użytkownikom w uniksowej grupie inf,
# patrz plik /etc/group
write list = @inf
###################################################################
[hpdj]
# tutaj udostępnimy drukarkę sieciową
# nazwa [hpdj] musi być identyczna jak w /etc/printcap
# tu wrzucane będą pliki tymczasowe wydruków, następnie kasowane
# po przesłaniu na drukarkę przez daemona lpd
path = /home/tmp
comment = HP Desk Jet 600
writable = yes
printable = yes
create mode = 0700
read only = yes
# ta drukarka jest tylko dla użytkowników uniksowej grupy pub
write list = @pub
# oraz wyłącznie z serwera i tych pecetów
hosts allow = 10.0.0.1 10.0.0.100 10.0.0.110
# tą komendą Samba będzie drukować
print command = /usr/bin/lpr -r -h -P %p %s
###################################################################
[pub]
# Zrobimy zasób dostępny dla wszystkich z naszej sieci Windows,
# posiadających konto na serwerze
# prawa na tym katalogu powinny być takie:
# drwxrwx--- 2 root pub 512 25 Sie 22:59 pub
path = /home/pub
volume = pub
comment = Katalog dla lokalnych
browseable = yes
# prawa muszą być także dla grupy, bowiem nikt z członków grupy
# nie mógłby nic zrobić z plikami innego członka grupy
create mode = 0770
directory mode = 0770
write list = @pub
oplocks = True
level2 oplocks = True
# dajemy dostęp do niego tylko z części sieci
hosts allow = 10.0.0.1/255.255.255.240
###################################################################
[goscie]
# Zróbmy katalog dla innej grupy
path = /home/goscie
volume = goscie
comment = Katalog dla wszystkich
browseable = yes
create mode = 0770
directory mode = 0770
write list = @goscie
oplocks = True
level2 oplocks = True
###################################################################
[bazy]
# Specjalna sekcja na potrzeby systemów bazodanowych, finansowo
# księgowych itp. Dostęp współdzielony bez oplock'ów
path = /home/bazy
volume = bazy
comment = Katalog baz danych
browseable = yes
create mode = 0770
directory mode = 0770
write list = @bazy
# zakaz stosowania agresywnego buforowania przez windows
oplocks = False
dos filetime resolution = True
###################################################################
[cdrom]
# Czasem trzeba coś zainstalować na pecetach z udostępninego
# i podmontowanego cdromu na uniksie :)
# drwxr-xr-x 2 root wheel 512 15 Kwi 17:45 cdrom
path = /cdrom
volume = cdrom
comment = Naped CDROM
read only = yes
fake oplocks = yes
locking = no
writable = no
share modes = no
###################################################################
[programy]
# a tu trzymamy różne programy dla pecetów
path = /home/programy
volume = programy
comment = Programy uzytkowe i nietylko
#read only = yes
create mode = 0775
directory mode = 0775
#fake oplocks = yes
oplocks = True
level2 oplocks = True
#locking = yes
#writable = no
#share modes = no
# oczywiście prawo zapisu ma tylko uniksowa grupa programy
write list = @programy
# czytać pliki może uniksowa grupa pub i goscie
read list = @pub, @goscie
hosts allow = 10.0.0.0/255.255.255.0
###################################################################
[www]
# użytkownicy naszej sieci wolą robić strony www lokalnie,
# na swoich komputerach, pracując z zamapowanego dysku serwera i
# strasznie nie lubią zabawy z użyciem ftp do wkopiowywania
# stron na serwer, tak więc Sambo! Do dzieła!
# prawa na tym katalogu powinny być takie:
# drwxr-xr-x 4 root pub 512 27 Sie 09:23 www
# a wewnątrz katalogi użytkowników dostępne ze świata poprzez
# Apache Web Serwer (co wymaga odpowiedniej konfiguracji apacza)
# articles 40 root wheel lrwxr-xr-x
# ~books 37 root wheel lrwxr-xr-x
# ~faq 18 root wheel lrwxr-xr-x
# ~handbook 23 root wheel lrwxr-xr-x
# ~samba 28 root wheel lrwxr-xr-x
# ~sharedoc 20 root wheel lrwxr-xr-x
# /tom 1024 tom nobody drwxr-x---
# /www.pit.com.pl 512 mikek nobody drwxr-x---
# index.html 688 webmaster webmaster -rw-rw-r--
# ...
#
path = /home/www
volume = www
comment = Dla stron WWW
create mode = 0775
directory mode = 0775
write list = @pub
oplocks = false
level2 oplocks = false
###################### KONIEC KONFIGURACJI ########################
###################################################################
KONFIGURACJA SIECI
Chcąc wykorzystać zdolność Samby do przechowywania zindywidualizowanych
ustawień użytkowników Windows® należy w odpowiedni sposób skonfigurować
sieć oraz włączyć profile (Rysunek 1).
Konfiguracja
sieci w Windows® wymaga zainstalowania protokołu TCP/IP, przyznaniu
adresu IP oraz kilku opcji. Adres IP musi być umieszczony, wraz z nazwą
peceta bądź w /etc/hosts na uniksie bądź w naszym DNS. Niezbędne jest
ustawienie nazwy "Netbios" peceta na zakładce "Identyfikacja" we
"Właściwościach Sieci", podanie tej samej grupy roboczej co w pliku
/etc/smb.conf, opisu komputera (Rysunek 2), a także logowania do domeny
NT. Nazwa domeny jest identyczna jak nazwa grupy roboczej (Rysunek 3).
W celu zapewnienia poprawnego wyświetlania zasobów naszych podsieci
musimy utrzymywać serwer WINS, którego rolę może pełnić Samba (o ile
parametry pliku sbm.conf na to zezwalają). Należy poinformować Windows®
o adresie serwera WINS, co musi być wykonane bezwzględnie na wszystkich
pecetach we wszystkich podsieciach pod rygorem niepoprawnej obsługi
tzw. "cross subnet browsing", czyli prezentacji udostępnianych zasobów
przez wszystkie komputery we wszystkich podsieciach (patrz dokumentacja
Samby).
Bardzo ważne jest poprawne ustawienie maski podsieci w konfiguracji
TCP/IP na pecetach. Błędna maska spowoduje błędne rozgłaszanie się
Windows gdyż użyją niepoprawnego adresu broadcast. Jest to źródłem
problemów powstających w relacji Samba - Windows, nieraz bardzo
trudnych do zidentyfikowania. Najprościej rzecz ujmując, maska musi być
identyczna jak na interfejsie serwera do którego dana podsieć jest
przyłączona (Rysunek 4).
Powyższe zasady zagwarantują późniejsze bezproblemowe
działanie naszej sieci wraz ze wszystkimi podsieciami. Przy większych
instalacjach oraz przy podziale na podsieci względem grup roboczych
(np. różne oddziały firmy w różnych miastach), warto zainstalować po
jednym z serwerów Samby w każdej jednostce, co zaoszczędzi nam i tak
małej przepustowości łącz międzyoddziałowych oraz zwiększy szybkość
działania lokalnych grup roboczych. W takiej sytuacji niezbędnym staje
się właśnie serwer WINS, z którego lokalne serwery oddziałowe będą
pobierać informacje o udostępnianych zasobach. W całej naszej rozległej
sieci powinien być wyłącznie jeden taki serwer i nie koniecznie musi
być nim Samba, jednak tutaj skupimy się na konfiguracji Samby
przystosowanej do tego celu. 
Pewnym skutkiem ubocznym jest długotrwałe utrzymywanie w otoczeniu
sieciowym komputerów udostępniających zasoby, nawet po ich fizycznym
wyłączeniu z prądu. Jedyną metodą skracającą ten czas jest ustawienie
poniższych parametrów w pliku /etc/smb.conf na serwerach Samby (mogą
wystąpić inne uboczne skutki przy zbyt małych czasach tak więc zależne
jest to od konkretnej instalacji, poniższe parametry wydają się być
optymalne dla kilku serwerów):
# skrócenie domyślnych czasów utrzymywania list zasobów w sieci
# domyślny czas utrzymywania nazw Netbios przez Sambę
max ttl = 10800
# domyślne czasy utrzymywania nazw Netbios przez WINS
max wins ttl = 36000
min wins ttl = 18000
Konfiguracja "domain master browser", na którym równocześnie będzie
działać serwer WINS, powinna wyglądać jak w poniższym przykładzie:
# domain master browser + WINS serwer
local master = yes
preferred master = yes
wins support = yes
os level = 64
Konfiguracja "local master browser", powinna wskazywać (jeżeli chodzi o WINS), na nasz główny serwer i wyglądać tak:
# lokalny serwer oddziału firmy
domain master = no
local master = yes
preferred master = yes
# adres serwera głównego, na którym jest nasz WINS
wins server = 10.0.0.1
max ttl = 10800
max wins ttl = 36000
min wins ttl = 18000
os level = 32
name resolve order = wins bcast hosts
Takie ustawienia wymuszają synchronizację pomiędzy serwerami lokalnymi, a głównym serwerem, na którym jest WINS.
PROFILE
Włączenie profili użytkowników wymusza na Windows®
utrzymywanie osobnych ustawień dla każdego użytkownika. Są one
przechowywane w podkatalogu "C:\WINDOWS\PROFILES\", gdzie tworzone są
katalogi o nazwach użytkowników. Każdy zawiera kompletne "MENU START" z
zawartością, osobny plik rejestru USER.DAT i inne. Przy pierwszym
wylogowaniu się z serwera, zawartość kopiowana jest do katalogu
domowego użytkownika (co zresztą określone jest w /etc/smb.conf).
Zalogowanie się do sieci powoduje zsynchronizowanie lokalnej i zdalnej
zawartości profilu i ewentualne jego skopiowanie z serwera na dysk
lokalny.
Pozwala to na przesiadkę na innego peceta gdzie po zalogowaniu do sieci
(przy włączonych profilach) Windows® udostępni nam nasze menu,
ustawienia itd. Ubocznym skutkiem jest kopiowanie tej struktury na
lokalne dyski (coś za coś) oraz tworzenie pliku z hasłami (*.pwl, można
to wyłączyć odpowiednim wpisem do rejestru, patrz dokumentacja Samby).
Logowanie do sieci wymusza na Windows® wykonanie skryptu startowego
(co określa odpowiedni wpis w /etc/smb.conf). Jest to zwyczajny plik
wsadowy (batch np. startup.bat) koniecznie edytowany w trybie MS-DOS
tzn. z CR+LF na końcach linii (np. $>joe -crlf startup.bat). Można
także skorzystać z konwersji pliku narzedziami unix2dos oraz dos2unix.
Ostatnia linia nie może powodować wywołania programu, z którego nie ma
powrotu np. wywołanie Norton Commander® itp. gdyż Windows® po prostu
się nam zawiesi. Poniższy przykład demonstruje główny plik startup.bat
z którego wywoływany jest plik zindywidualizowany startup.bat z
katalogu domowego użytkownika:
@echo off
REM Główny startup.bat w katalogu netlogon
REM \\venom\netlogon\startup.bat powinien mieć np. takie prawa:
REM -rw-rw-r-- 1 root wheel 277 4 Sie 10:58 startup.bat
REM
REM Synchronizacja daty i czasu z serwerem
net time \\venom /set /yes
REM mapowanie dysków
net use u: /home /yes
net use p: \\venom\pub /yes
net use r: \\venom\programy /yes
net use s: \\venom\goscie /yes
net use y: \\venom\cdrom /yes
REM Jeśli jest prywatny to go uruchamiamy
if exist u:\startup.bat call u:\startup.bat
Po wykonaniu tego skryptu, zostanie również wykonany skrypt
użytkownika "startup.bat" o ile istnieje w jego katalogu domowym na
dysku U:. Pozwala to na indywidualne traktowanie użytkowników, na
dostosowywanie środowiska pracy użytkowników oraz pozwala im na edycję
tych ustawień:
@echo off
REM Plik startowy indywidualny użytkownika
REM powinien być w katalogu $HOME użytkownika i mieć prawa:
REM -rw------- 1 pit pit 106 3 Lip 18:51 startup.bat
REM mapowania dysków wykonywane w tym pliku,
REM przykrywają mapowania wykonane w globalnym startup.bat
REM
net use k: \\venom\bazy /yes
net use w: \\venom\www /yes
REM mapowanie drukarki
net use LPT3 \\venom\hpdj /yes
DOMENY PDC
Samba w wersji 2.0.9 potrafi współpracować z
domenami Windows NT® jednak z Windows 2000® występują pewne problemy,
które mają zostać usunięte w kolejnej wersji Samby. Zakładamy że
kontrolerem domeny jest Windows® (NT lub 2000), on też obsługuje serwer
WINS, i "domain master browser". Wymagane parametry w pliku
konfiguracyjnym /etc/smb.conf wyglądają wtedy następująco:
# konfig dla pracy z kontrolerem domeny NT
security = domain
#password server =
password server = 10.0.0.200 10.0.0.201
encrypt passwords = yes
socket options = TCP_NODELAY IPTOS_LOWDELAY IPTOS_THROUGHPUT
# os level = 0 załatwia sprawę współzawodnictwa z Windows NT master browse
# do wymaganego minimum
os level = 0
#domain controller =
domain controller = 10.0.0.200
#wins server =
wins server = <10.0.0.200>
dns proxy = no
Niezbędne jest także dokładne przestudiowanie dokumentacji
Samby, opisującej w jaki sposób należy skonfigurować Windows® i Sambę w
celu przystosowania ich do takiego trybu pracy. Ten artykułu ma jedynie
zasygnalizować taką możliwość, dlatego nie będziemy się zagłębiać w tym
kierunku wyręczając autorów Samby w przekazywaniu nam swojej wiedzy.
:-)
UŻYTKOWNICY
Zakładając, że wykonaliśmy instalację i
konfigurację Samby, dodajmy teraz użytkowników do naszego serwera.
Powinniśmy tutaj posłużyć się standardowym dla naszego uniksa
narzędziem, przy czym dla użytkowników wyłącznie sieci Windows, nie
przydzielamy shella (bo i po co?). Wyjątkowo dla użytkowników
posiadających konto pocztowe na tym samym serwerze, możemy przydzielić
zamiast shell'a program "passwd" do zmiany hasła uniksowego.
Przydzielanie programu "smbpasswd" jest niecelowe, bowiem użytkownik ma
możliwość zmiany hasła sieciowego Windows® z "Panelu Sterowania" (ikona
"Hasła"). Jest to także naruszeniem bezpieczeństwa. Podawanie jawnym
tekstem nowego hasła sieciowego (jak to jest w przypadku passwd i
smbpasswd) może być podsłuchane i wykorzystane do nieuprawnionego
dostępu do zasobów serwera. Najlepszym rozwiązaniem jest całkowite
wyłączenie shell'a lub udostępnienie bardziej zaawansowanym
użytkownikom konta uniksowego, z wyłączną możliwością zalogowania się
przy użyciu szyfrowanych protokołów (np. ssh). Polecam tu szczególnie
darmowy program terminala dla Windows® - PuTTY SSH.
$>smbpasswd -a adam
added interface ip=10.0.0.1 bcast=10.0.0.255 nmask=255.255.255.0
New SMB password:
Retype new SMB password:
User adam does not exist in system password file (usually /etc/passwd).
Cannot add account without a valid local system user.
Failed to modify password entry for user adam
Jak widać Samba wyraźnie zmusza nas do wcześniejszego założenia
użytkownika w uniksie. Kiedy Konto uniksowe jest już założone, katalog
domowy utworzony a prawa poprawnie ustawione możemy przejść do dodania
użytkownika do Samby.
$>smbpasswd -a pit
added interface ip=10.0.0.1 bcast=10.0.0.255 nmask=255.255.255.0
New SMB password:
Retype new SMB password:
$>
Skutkuje to dopisaniem do pliku użytkowników. Zwykle jest on w
katalogu "/usr/local/samba/private/" jednak to może zostać zmienione,
na etapie konfiguracji i kompilacji Samby.
$>cd /usr/local/samba
$> ls -ld private
drwx------ 2 root wheel 512 14 Sty 2000 private
$>cd private
$>ls -l
-rw-r--r-- 1 root wheel 41 14 Sty 2000 MACHINE.SID
-rw------- 1 root wheel 557 9 Wrz 14:40 smbpasswd
$>cat smbpasswd
pit:2004:DD02BA4D905304F3AAD3B435B51404EE:BE21EF1208C298133C9CB4AD2791E55A:[U ]:LCT-3989BF65:
Narzędzie smbpasswd ma wiele dodatkowych opcji, pozwalających
na blokowanie dostępu, zmianę lub usunięcie hasła, usunięcie
użytkownika, dodanie do domeny NT itp. Szczególnym trybem działania
jest przejście Samby z haseł nieszyfrowanych na szyfrowane, co także
opisuje dokumentacja. Samba działając na nieszyfrowanych hasłach
posługuje się standardowymi plikami haseł uniksa i nie wymaga dodawania
użytkowników do Samby.
Pamiętajmy jednak że wtedy z poziomu panelu sterowania Windows® nie
można zmienić hasła i trzeba to robić tradycyjnym uniksowym passwd.
Pamiętajmy że smbpasswd działa w trybie klient-serwer dlatego wymagane
jest aby uniks jako "localhost" miał zezwolenie na dostęp do Samby
(polecam zapoznanie się z plikami *.TXT z dokumentacji Samby).
Bardzo pomocnym narzędziem w codziennym działaniu Samby jest
"smbstatus", pokazujący stan wszystkich połączeń z Sambą, otwarte
pliki, blokady itp.:
$>smbstatus
Samba version 2.0.9
Service uid gid pid machine
----------------------------------------------
pit pit pit 3854 stone (10.0.0.100) Wed May 9 13:48:48 2000
hpdj pit pit 3854 stone (10.0.0.100) Wed May 9 14:10:13 2000
www pit pit 3854 stone (10.0.0.100) Wed May 9 15:15:19 2000
bazy pit pit 3854 stone (10.0.0.100) Wed May 9 15:15:33 2000
Locked files:
Pid DenyMode R/W Oplock Name
--------------------------------------------------
3854 DENY_NONE RDWR NONE /home/bazy/mag/MAG_02/ZAM_PART.DBF Wed May 9 15:16:52 2000
3854 DENY_NONE RDWR NONE /home/bazy/mag/MAG_02/OBROTY.DBF Wed May 9 15:16:52 2000
3854 DENY_NONE RDWR NONE /home/bazy/mag/CENNIK1.NTX Wed May 9 15:16:52 2000
3854 DENY_NONE RDWR NONE /home/bazy/mag/CENY_DW3.NTX Wed May 9 15:16:52 2000
3854 DENY_WRITE RDWR EXCLUSIVE+BATCH /home/pit/startup.bat Wed May 9 15:15:27 2000
3854 DENY_NONE RDONLY EXCLUSIVE+BATCH /home/pit/S.TXT Wed May 9 14:16:27 2000
Share mode memory usage (bytes):
1042512(99%) free + 5176(0%) used + 888(0%) overhead = 1048576(100%) total
Na powyższym zestawieniu widać, że w przypadku plików bazy
danych Samba nie stosuje oplock'a (zezwolenia na agresywne cache'owanie
pliku przez windows) natomiast plik S.TXT ma właśnie taki tryb dostępu.
Zamknięcie pliku nadal nie jest widoczne bowiem jest on w dyspozycji
peceta aż do momentu, gdy jakiś inny komputer poprosi Sambę o otwarcie
tego samego pliku. Następuje wtedy negocjacja Samby z obydwoma
komputerami, która objawia się dla użytkowników chwilowym zablokowaniem
Windows®.
W tym czasie, Samba kontaktuje się z klientem który jako pierwszy
otrzymał oplock do pliku. Windows po otrzymaniu rozkazu przerwania
oplock'a wie, że nie może już korzystać z buforowania pliku i musi
czytać go ponownie z serwera. Drugi klient po całej tej "rozmowie"
otrzymuje dostęp do pliku. Może to trwać kilka do kilkunastu sekund. W
tym czasie obydwa komputery są zablokowane, co czasem ma wpływ na ich
właścicieli i kończy się przedwczesnym zresetowaniem komputera, przez
zniecierpliwionego użytkownika. Można ten czas regulować jednak
domyślne wartości wydają się być optymalne. Najlepiej uprzedzić
użytkowników a takich skutkach ubocznych, informując że niestety jest
to niezbędne, jeżeli chcemy mieć bardzo wydajny serwer plików.
Explorator Windows® ma tendencję do zczytywania początków
plików przy przeglądaniu zawartości dysków (np. w celu rozpoznania typu
pliku, odczytaniu ikony itp.). Ta cecha powoduje że pliki "hurtowo"
zostają otwierane w trybie oplock. Kiedy z takiego katalogu korzysta
wielu użytkowników najlepiej jednak będzie zrezygnować z oplock'ów.
Częściowo zostało to poprawione w Sambie, poprzez wprowadzenie
parametru:
"level2 oplocks = True"
Z moich doświadczeń
wynika, że ten tryb blokowania plików najlepiej sprawdza się w
katalogach domowych użytkowników, zapewniając maksymalną wydajność
Samby a także w niewielkich grupach roboczych. Tam gdzie z zasobu
korzysta duża liczba użytkowników, najlepiej od razu wymusić na Sambie
pracę bez oplock'ów.
SZYBKOŚĆ
Samba w przypadku sieci, gdzie ilość stacji roboczych
jest niewielka, wykazuje się transferami podobnymi jak Windows® NT czy
2000. Gdy liczba klientów wzrasta, zaczynamy dostrzegać przewagę Samby
jako
serwera plików i drukarek. Samba doskonale radzi sobie z obciążeniami
rzędu kilkudziesięciu pecetów. Wąskim gardłem jest sieć oraz szybkość
dysków i tak:
Serwerek AMD-K6 233MHz 32MB RAM 20GB HDD IBM 5400rpm FreeBSD 3.5 Samba 2.0.9
Sieć: | 10Mbit Half Duplex | 100Mbit FullDuplex
-----------|---------------------|----------------------
Transfery: | 800.000 bajtów/sek. | 3.200.000 bajtów/sek.
Test wykonany poprzez zwyczajne kopiowanie około 200MB plików systemu magazynowego.
Protokoły CIFS Samby są w stanie uzyskać około 80% przepustowości sieci.
Transfer maksymalny na sieci 100Mbit nie został osiągnięty z braku szybszych dysków :)
Samba zużywa około 2-3 MB RAM na każdego klienta. Z tym że przy
bezczynności klienta, pamięć jest zwalniana -poprzez zrzut do swap'u- o
ile jest to konieczne i wymagane przez serwer uniksowy. Nie wszytkie
uniksy tak się zachowują. W przypadku braku pamięci robi tak np.
FreeBSD, natomiast nie robi tego Linux. Stąd zwyczajny komputer
działający jako niewielki serwerek z 32MB RAM oraz z systemem FreeBSD,
doskonale obsługuje sieć złożoną z 25 komputerów.
ZAKOŃCZENIE
Niniejszy artykuł został napisany dla miesięcznika
"SOFTWARE", do numeru specjalnego poświęconego systemom FreeBSD,
NetBSD, OpenBSD.
Nie omawiam w nim wielu specyficznych parametrów dla każdego
z nich, np. parametrów kernela FreeBSD pozwalających na trzymanie
blokad plików przez Sambę w pamięci współdzielonej zamiast w pliku
dyskowym,
zwiększenia ilości możliwych do otwarcia plików itp. (można o tym
przeczytać w dokumentacji twojego systemu uniks - konfiguracja kernela,
opcje dotyczące SYSV). Być może wersja online będzie bardziej
rozbudowana i poruszy jeszcze wiele innych aspektów działania sieci
Windows® z serwerem Samba na pokładzie systemów BSD. Ilość
specyficznych parametrów dla każdego z nich jest bardzo duża.
Przedstawianie ich tutaj daleko wykracza poza ramy artykułu i mieści
się raczej w kategorii "zaawansowana administracja i konfiguracja w
systemach uniksowych BSD". Początkujący administrator powinien zaufać
programom konfigurującym ("configure" w dystrybucji) i przygotowującym
pakiet Samby do kompilacji.
Najnowsza wersja tego opracowania jest dostępna pod adresem:
http://bofh.vt.pl
Dodatkowe informacje można uzyskać kontaktując się z autorem:
Bartek Siębab
Grupa dyskusyjna USENET: news://comp.protocols.smb
Oficjalne strony projektu Samba: http://www.samba.org